Subject: Correct version 0.12 DLSW (3 of 8) (Resent with file)

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Fri, 19 Aug 94 18:13:16 PDT

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 7
X-Sun-Content-Length: 207

This is part 3 of 8 with the file actually attached, (Sorry about
the error, it's Friday night late at work and I'm tired.
Please disregard the previous (3 of 8) message.

Regards and apologies,

Alan

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: dlsw3.txt
X-Sun-Content-Lines: 567
X-Sun-Content-Length: 24402

RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

4. Circuit Priority

   At circuit start time, each circuit end point will provide suggested priority
   information to its circuit partner.  The initiator if the circuit will choose
   which circuit priority will be effective for the life of the circuit.

4.1. Frame format:

   Circuit priority will be valid in the CANUREACH_cs, ICANREACH_cs, and REACH_ACK
   frames only. The relevant header field is shown below.  The Circuit Priority
   value is at offset 22 in an SSP Control Message.

   The following describes the format of the Circuit Priority byte.

     7   6   5   4   3   2   1   0
   +-----------------------+-------+
   |   reserved            |  CP   |
   +-----------------------+-------+

   CP: Circuit Priority bits
            00 - Low Priority
            01 - Medium Priority
            10 - High Priority
            11 - Highest Priority

   These values were chosen to correspond to the SNA INN FID4 TH TPF and NTWK_PRTY
   fields.

4.2. Circuit Startup:

   The sender of a CANUREACH_cs is responsible for setting the CP bits to reflect
   the priority it would like to use for the circuit being requested.  The
   mechanism for choosing an appropriate value is implementation dependent.  The
   sender of an ICANREACH_cs frame will set the CP bits to reflect the priority it
   would like to use for the circuit being requested, with the mechanism for
   choosing the appropriate value being implementation dependent.  The receiver of
   the ICANREACH_cs will select from the 2 possible priorities and will set the
   value in the CP field of the REACH_ACK frame that follows to the value to be
   used for this circuit.  This priority will be used for the life of the circuit.

   Flow:

         DLSw A               DLSw B

    CANUREACH_cs (CP=10) ------->                Circuit initiator requests
                                                    high Priority.

           <---------   ICANREACH_cs (CP=01)     Circuit target requests
                                                    medium priority.

    REACH_ACK (CP=01)   -------->                Circuit initiator sets
                                                    the priority for this
                                                    circuit to medium. The
                                                    circuit initiator could
                                                    choose any valid value.

AIW DLSw Related Interest Group                                  [Page 20]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

5. Capabilities Exchange Formats/Protocol:

   The Data Link Switching Capabilities Exchange is formatted as a single General
   Data Stream (GDS) Variable with multiple type "LT" structured subfields.

   The DLSw Capabilities Exchange Request has the following overall format:

       +----+----+-----------------+
       | LL | ID | Control Vectors |
       +----+----+-----------------+

       0-1         Length, in binary, of the DLSw Capabilities Exchange
                   Request GDS Variable.  The value of LL is the sum of
                   the length of all fields in the GDS Variable (i.e.
                   length of LL + length of ID + length of Control
                   Vectors).

       2-3         GDS Id: 0XF000

       4-n         Control Vectors consisting of type LT structured subfields
                   (i.e. the DLSw Capabilities Exchange Structured Subfields)

   Type LT structured subfields consist of a 1-byte length field (the "L"), a 1-
   byte type field (the "T") and n-bytes of data.  The length field includes itself
   as well as the structured subfield.  The structured subfield consists of the
   type field and data so the length is n + 2.  This imposes a length restriction
   of 253 bytes on all data contained in a structured subfield.

5.1. Control Vector Id Range

   Control Vector identifiers (i.e. Type) in the range of 0x80 through 0xCF are
   reserved for use by the Data Link Switching standard.

   Control Vector identifiers (i.e. Type) in the range of 0xD0 through 0xFD are
   used for vendor-specific purposes.

   Currently defined vectors are:

     Vector Description                 Hex Value

     Vendor Id Control Vector           0x81
     DLSw Version Control Vector        0x82
     Initial Pacing Window Control Vector    0x83
     Version String Control Vector      0x84
     NetBIOS Support Control Vector     0x85
     SAP Support Control Vector         0x86
     TCP Sessions Control Vector        0x87
     Exclusivity Control Vector         0x88
     MAC Address List Control Vector    0x89
     NetBIOS Name List Control Vector   0x8A
     Reserved for future use            0x8B - 0xCF
     Vendor Specific                    0xD0 - 0xFD

AIW DLSw Related Interest Group                                  [Page 21]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

5.2. Control Vector Order and Continuity

   Since their contents can greatly affect the parsing of the Capabilities Exchange
   GDS Variable, the required control vectors must occur first and appear in the
   following order:  Vendor Id, DLSw Version Number, Initial Pacing Window,
   Supported SAP List. The remainder of the Control Vectors can occur in any order.

   Control Vectors that can be repeated (i.e. MAC Address List Control Vector and
   NetBIOS Name List Control Vector) are not necessarily adjacent.  It is
   advisable, but not required, to have the Exclusivity Control Vector occur prior
   to either of the above two vectors so that the use of the individual MAC
   addresses or NetBIOS names will be known prior to parsing them.

5.3. Run-Time Capabilities Exchange

   Capabilities exchange always occurs when the SSP connection is started between
   two DLSw switches.  A run-time Capabilities Exchange may also be issued to
   modify a subset of the data exchanged when the link was started.  The only
   vectors permitted on a run-time Capabilities exchange are:

     1. Exclusivity CV,
     2. MAC Address List CV, and
     3. NetBIOS Name List CV.

   A run-time capabilities exchange is a replacement operation.  As such, all
   pertinent MAC addresses and NetBIOS names must be specified in the run-time
   exchange.

5.4. DLSw Capabilities Exchange Structured Subfields

   The Capabilities Exchange Subfields are listed in the table below and are
   described in the following sections:

     ID    Required? Length  Runtime?  Content
     ======================================================================
    x81        Y      x05      N       Vendor ID
    x82        Y      x04      N       DLSw Version
    x83        Y      x04      N       Initial pacing window
    x84        N      x02-n    N       Version String (vendor defined)
    x85        N      x03      N       NetBIOS Support
    x86        Y      x04      N       SAP Support
    x87        N      x03      N       TCP Sessions
    x88        N      x03      Y       Exclusivity
    x89        N      x0E      Y       MAC Address List
    x8A        N      <=x12    Y       Netbios Name List

5.4.1. Vendor Id (0x81) Control Vector

   The Vendor Id control vector identifies the manufacturer's IEEE assigned
   Organizationally Unique Identifier (OUI) of the Data Link Switch sending the
   DLSw Capabilities Exchange.  The OUI is sent in non-canonical (Token-Ring)
   format.  This control vector is required and must be the first control vector.

AIW DLSw Related Interest Group                                  [Page 22]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x05        Length of the Vendor Id structured
                                       subfield
              1       1    0x81        key = 0x81  that identifies this as the
                                       Vendor Id structured subfield
             2-4      3                the 3-byte Organizationally Unique
                                       Identifier (OUI) for the vendor
                                       (non-canonical format)

5.4.2. DLSw Version (0x82) Control Vector

   The DLSw Version control vector identifies the particular version of the DLSw
   standard supported by the sending Data Link Switch.  This control vector is
   required and must follow the Vendor Id Control Vector.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x04        Length of the Version String structured
                                       subfield
              1       1    0x82        key = 0x82  that identifies this as the
                                       DLSw Version structured subfield
             2-3      2                the hexadecimal value representing the
                                       DLSw standard of
                                       the sending Data Link Switch.
                                         0x01, 0x00

5.4.3. Initial Pacing Window (0x83) Control Vector

   The Initial Pacing Window control vector specifies the initial value of the
   receive pacing window size for the sending Data Link Switch.  This control
   vector is required and must follow the DLSw Version Control Vector.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x04        Length of the Initial Pacing Window
                                       structured subfield
              1       1    0x83        key = 0x83  that identifies this as the
                                       Initial Pacing Window structured subfield
             2-3      2                the pacing window size.

5.4.4. SAP List Support (0x86) Control Vector

   The SAP List Support control vector identifies support for SAPs by the sending
   Data Link Switch. Each bit in the SAP control vector data field represents a SAP
   as defined below. This vector is required.

   NetBios support is determined by the "AND" of the NetBios Support control vector
   and the NetBios SAP bit in the SAP List Support control vector. If either
   indicates that NetBios is supported, the sending Data Link Switch supports
   NetBios.

AIW DLSw Related Interest Group                                  [Page 23]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   Offset  Length  Value       Contents
   ------  ------  -----       --------
      0       1     0x03       Length of the SAP List Support structured
                               subfield
      1       1     0x86       key = 0x86 that identifies this as the SAP
                               List Support structured subfield
      2       4                Supported SAP vector -  bitwise "OR" of
                               SAP masks for each supported SAP.
                               <mask>                <supp sap>
                               0x0001 - NULL SAP       0x00
                               0x0002 - SNA  SAP       0x04
                               0x0004 - SNA  Group SAP 0x05
                               0x0008 - SNA  SAP       0x08
                               0x0010 - SNA  SAP       0x0C
                               0x0020 - Span Tree SAP  0x42
                               0x0040 - NetBios SAP    0xF0
                               0x0080 - LNM SAP        0xF4
                               0x0100 - LNM Group SAP  0xF5
                               0x0200 - RPL SAP        0xF8
                               0x0400 - Global SAP     0xFF
                               0x0800 - 0x8000' Reserved

   EDITOR'S NOTE:  THE ABOVE LIST IS WHAT WAS SUBMITTED BY FRANK BORDARO OF CISCO
   SYSTEMS.  MY UNDERSTANDING OF THE AGREEMENT AT THE LAST AIW MEETING WAS A
   COMPLETE "BIT-MASK" OF ALL POSSIBLE SAPS AS A 16 BYTE FIELD.  THE ABOVE LIST
   WILL NOT WORK WITH DOWN-STREAM SDLC CONVERTERS AS THEY MUST USE OTHER SAPS TO
   TERMINATE MULTIPLE PU'S PER MAC ADDRESS.  THIS FIELD WILL NEED FURTHER
   DISCUSSION BY BOTH THE CONNECT AND CAPABILITIES WORKING GROUPS.  FRANK'S
   PROPOSAL ALSO CALLED FOR A CHANGE TO SAY THAT IF YOU HAVE THE SAP VALUE IN THE
   BIT MASK, THE USE OF THE NETBIOS VECTOR IS OPTIONAL.  IF YOU SUPPORT NETBIOS,
   THEN YOU SHOULD NOT REQUIRE THE DATA LINK SWITCH TO HAVE TO PARSE BITS TO FIND
   OUT.  FOR NOW I HAVE CHANGED THE TEXT ABOVE THAT FRANK HAS SUBMITTED TO USE AN
   "AND" FUNCTION.

5.4.5. Version String (0x84) Control Vector

   The Version String control vector identifies the particular version number of
   the sending Data Link Switch.  The format of the actual version string is
   vendor-defined.  This control vector is optional.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0xn         Length of the Version String structured
                                       subfield
              1       1    0x84        key = 0x84  that identifies this as the
                                       Version String structured subfield
             2-n     n-2               the ASCII string that identifies the
                                       software version for the sending DLSw.

5.4.6. NetBIOS Support (0x85) Control Vector

   The NetBIOS Support control vector identifies support for the NetBIOS protocol
   by the sending Data Link Switch.  This control vector is optional.  If it is
   omitted in a DLSw Capabilities Exchange, then no NetBIOS support is assumed.

AIW DLSw Related Interest Group                                  [Page 24]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x03        Length of the NetBIOS Support structured
                                       subfield
              1       1    0x85        key = 0x85  that identifies this as the
                                       NetBIOS Support structured subfield
              2       1                an indicator of the support for NetBIOS
                                       by the Data Link Switch.
                                       0x00        NetBIOS is not supported by
                                                   the sender
                                       0x01        NetBIOS is supported by the
                                                   sender

AIW DLSw Related Interest Group                                  [Page 25]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

5.4.7. TCP Sessions (0x87) Control Vector

   The TCP Sessions control vector indicates the support of an alternate number of
   TCP sessions for the Data Link Switching traffic.  The base implementation of
   Data Link Switching supports two TCP sessions, one for each direction of data
   traffic.

   This control vector is optional.  If it is omitted in a DLSw Capabilities
   Exchange, then two TCP sessions are assumed.  It is further assumed that if a
   Data Link  Switch can support one TCP session, it can support two TCP sessions.

   The pseudo-code below shows the logic for determining the number of TCP sessions
   to use:

          if TCP Sessions CV values agree, then
              use the number of sessions in CapEx
              if the number of sessions is one, then
                  if IP address of this DLSw > IP address of
                     partner DLSw, then
                      drop the TCP session for port 2065
                  else
                      do nothing: other DLSw will drop the extra
                      TCP session
                  endif
              else
                  do nothing: use 2 TCP sessions
              endif
          else
              num TCP sessions disagree: use 2 TCP sessions
          endif

   The format of the TCP Sessions Control Vector is shown below:

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x03        Length of the TCP Sessions structured
                                       subfield
              1       1    0x87        key = 0x87  that identifies this as the
                                       TCP Sessions structured subfield
              2       1                an indicator of the support for an
                                       alternate number of TCP sessions by
                                       the sending Data Link Switch.
                                         0x01      the number of TCP sessions
                                                   may be brought down to one
                                                   after Capabilities Exchange
                                                   is completed.
                                         0x02      the number of TCP sessions
                                                   will remain at two for
                                                   the duration of the DLSw
                                                   connection.

AIW DLSw Related Interest Group                                  [Page 26]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

5.4.8. Exclusivity (0x88) Control Vector

   The Exclusivity control vector identifies how the MAC Address List and NetBIOS
   Name List control vector data is to be interpreted.  Specifically, this control
   vector identifies whether the MAC addresses and NetBIOS names are the only ones
   accessible via the sending Data Link Switch.

   If either of the above control vectors is specified and the Exclusivity control
   vector is missing, then the MAC addresses and/or NetBIOS names are not assumed
   to be the only ones accessible via this switch.

   If neither of the above control vectors is specified and the Exclusivity control
   vector is present, this indicates that the sending Data Link Switch does not
   wish to receive any CANUREACH messages.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x03        Length of the Exclusivity structured
                                       subfield
              1       1    0x88        key = 0x88  that identifies this as the
                                       Exclusivity structured subfield
              2       1                an indicator of the relationship of the
                                       MAC addresses and/or NetBIOS names to
                                       the sending Data Link Switch
                                         0x00      the MAC addresses and/or
                                                   NetBIOS names specified in
                                                   this Capabilities Exchange
                                                   can be accessed via this
                                                   switch but are not the
                                                   exclusive set (i.e. other
                                                   entities are accessible in
                                                   addition to the ones specified)
                                         0x01      the MAC addresses and/or
                                                   NetBIOS names specified in
                                                   this Capabilities Exchange
                                                   are the only ones accessible
                                                   via this switch.

5.4.9. MAC Address List (0x89) Control Vector

   The MAC Address List control vector identifies one or more MAC addresses that
   are accessible through the sending Data Link Switch.  This control vector
   specifies a single MAC address value and MAC address mask value to identify the
   MAC address or range of MAC addresses.  MAC addresses and masks are in non-
   canonical (Token-Ring) format in this control vector.

   EDITOR'S NOTE:  FRANK'S CONTRIBUTION, HAD THIS IN CANONICAL FORMAT (I CHANGED
   THIS).  AT THE AIW WE AGREED THAT ALL ADDRESSES WOULD BE IN NON-CANONICAL FORMAT
   AND THAT THE MIB WOULD BE THE ONLY THING THAT WOULD DEAL IN CANONICAL FORMAT.

   This control vector is optional and can be repeated if necessary.

AIW DLSw Related Interest Group                                  [Page 27]
RFC XXXX      DLSw: Switch-to-Switch Protocol              August 1994

   Note 1: If a particular MAC address, <mac-addr>, satisfies the following
   algorithm, then <mac-addr> is assumed to be accessible via the sending Data Link
   Switch:

   <mac-addr> & <mac-addr-mask> == <mac-addr-value>

   where:  <mac-addr-value> is the MAC Address
                            Value specified in
                            this control vector

           <mac-addr-mask>  is the MAC Address
                            Mask specified in
                            this control vector

   Note 2:  If an individual MAC Address is desired, then <mac-addr-value> should
   be the individual MAC address and <mac-addr-mask> should be 0xFFFFFFFFFFFF.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0x0E        Length of the MAC Address List
                                       structured subfield
              1       1    0x89        key = 0x89  that identifies this as the
                                       MAC Address List structured subfield
             2-7      6                the 6-byte MAC Address Value,
                                       <mac-addr-value> in the above formula
             8-13     6                the 6-byte MAC Address Mask,
                                       <mac-addr-mask> in the above formula

5.4.10. NetBIOS Name List (0x8A) Control Vector

   The NetBIOS Name List control vector identifies one or more NetBIOS names that
   are accessible through the sending Data Link Switch.  This control vector
   specifies a single NetBIOS name in ASCII.  However, the NetBIOS name can consist
   of "don't care" and "wildcard" characters to match on a number of NetBIOS names.
   If an individual character position in the NetBIOS name in this control vector
   contains a '?', then the corresponding character position in real NetBIOS name
   is a "don't care".  If a NetBIOS name in this control vector ends in '*', then
   the remainder of real NetBIOS names is a "don't care".

   All blanks or nulls at the end of NetBIOS names in this control vector are
   ignored.

   This control vector is optional and can be repeated if necessary.

           Offset  Length  Value       Contents
           ------  ------  -----       --------
              0       1    0xn         Length of the NetBIOS Name List
                                       structured subfield (maximum = 0x12)
              1       1    0x8A        key = 0x8A  that identifies this as the
                                       NetBIOS Name List structured subfield
             2-n     n-2               the NetBIOS name with possible embedded
                                       '?' and terminating '*'.

5.5. Capabilities Exchange Responses

   There are two kinds of DLSw Capabilities Exchange Responses: positive and
   negative.  A positive response is returned to the sending Data Link Switch if

AIW DLSw Related Interest Group                                  [Page 28]